Transparent Interconnection over Lots of Links (TRILL) is a Layer-2 (L2) network standard recommended by the Internet Engineering Task Force (IETF), and is adopted to overcome a shortcoming of a Spanning Tree Protocol (STP) in a large Data Center (DC). In an L2 network, the STP avoids a loop by blocking a redundant link, but also causes the bandwidth waste (blockage) of the redundant link. A TRILL network solves the problem of L2 loops by introducing an Intermediate System to Intermediate System (IS-IS) routing protocol into the L2 network, and meanwhile, L2 multiple path (or called Equivalent Cost Multiple Path (ECMP)) is reserved.
In the TRILL network, equipment running a TRILL protocol is called a Routing Bridge (RBridge) which is uniquely identified by a Nickname. At the ingress of the TRILL network, the RBridge responsible for encapsulating an original data frame of an End Station into a TRILL format (that is, a TRILL header and an external frame header are added in front of the original data frame, and the TRILL header mainly includes Nicknames and hop numbers of the RBridges at the ingress and egress of the TRILL network) and inputting the TRILL data frame into the TRILL network is called an ingress RBridge, Ingress for short; and at the egress of the TRILL network, the RBridge responsible for decapsulating the TRILL data frame into the original data frame and forwarding the original data frame to the End Station is called an egress RBridge. Egress for short, and meanwhile, the Egress can also learn about that the original data frame is imported into the TRILL network from which Ingress and form a Media Access Control (MAC) information table {D_MAC, Ingress_ Nickname, . . . }. Because being located on an edge part in the TRILL network, the Ingress and Egress RBridges are also called Edge RBridges.
In order to avoid the loop, on a border of the TRILL network, service can be provided for an end system by only one RBridge in any Virtual Local Area Network (VLAN), and the RBridge is called a service provider of the end system, such as a VLAN-x Appointed Forwarder (AF) on a shared link. Such a regulation can effectively avoid the loop, but also causes some problems, for instance, the switching of the AF on the shared link causes the flip-flop of Ingress_Nickname in some MAC entries on a far-end Egress; and in case of multi-homing of the end system to multiple RBridges through point-to-point links (for instance, a Link Aggregation Group (LAG)), in order to avoid the flip-flop of MAC on the far-end. RBridge, the links can only work in an Active-Standby mode to cause bandwidth waste and a difficulty in meeting the requirements of high throughput and high reliability of a high-performance DC.
Thus a TRILL working team puts forwards the concept of RBridge Group (RBG) or Virtual RBridge (RBv). In an RBG, a Nickname called a group Nickname is shared by members, and the RBv members notify own Group Nickname in the TRILL network to help other RBridges to calculate paths leading to the RBv. When a data frame is forwarded, the member RBridges finish the TRILL encapsulation of original data by virtue of the group Nickname rather than own equipment Nickname, so that the regulation is broken and the problem of flip-flop is solved.
After the introduction of the concept of RBv, the far-end RBridge can reach the RBv through multiple member RBridges. Traffic between the RBv and the far-end RBridge in different directions is input into and output from the TRILL network through different member RBridges. FIG. 1 is a schematic diagram of different forwarding paths of the RBv members for messages between host computers according to a related art, and as shown in FIG. 1, for example, traffic from H1 to H2 reaches H2 through RB1→ . . . →RB3 in FIG. 1 (it is supposed that the traffic is allocated to RB1 in a payload allocation way through Short Waves (SW)), and traffic from H2 to H1 reaches H1 through RB3→ . . . →RB2 (it is supposed that a path from RB3 to RB2 is superior to that from RB3 to RB1), so that forwarding information which can reach H2 through RB3 cannot be acquired by RB1 in a self-learning manner. Under the condition that RB1 does not know how to reach. H2, RB1 will encapsulate a data frame transmitted from H1 to H2 in form of unknown (destination) unicast frame, and multicasts the traffic in the TRILL network.
The above-mentioned multicast forwarding manner causes the arrival of the H1→H2 traffic at the irrelevant RB5, which leads to network bandwidth waste and consumption on a part of message processing resources of RB3. In case of heavy traffic from H1 to H2, the problems of bandwidth waste, consumption on the message processing resources and the like, which are caused by the loss of the forwarding information, are unbearable. In order to solve the problems, an efficient MAC information sharing mechanism among the member RBridges is required.
Although providing a way of rapidly notifying MAC address information among different RBridges, an End Station Address Distribution Information (ESADI) protocol only allows the notification of a local MAC address at present, that is, the RBridges can reach an MAC address of the end system without the other RBridges. Besides local MAC address information, far-end MAC information is also required to be shared among the RBv members and learnt by the members, that is, the RBridges can reach the MAC address of the end system only through the other RBridges. Therefore, the conventional ESADI protocol cannot meet the requirement of information sharing among the RBv members.
The introduction of an RBv group is mentioned in the related art, and after the RBv group is introduced, the member RBridges must share acquired information such as the MAC address information to one another in the group to enable the members to better provide service for the end system, for example, when message forwarding service is provided for the end system across the TRILL network, unnecessary multicast forwarding of an unknown unicast message is avoided. At present, the prior art is unsuitable for intra-group information sharing such as MAC information sharing. In the TRILL network, a MAC address information format on the Edge RBridge is different from that in a conventional network (for example, the far-end MAC information additionally has a Nickname field of the egress RBridge), so that the problem of MAC address between RBvs cannot be solved by the prior art. The conventional VLAN-granularity-based ESADI cannot ensure to control a sharing range of the MAC address information and an Operation Administration Maintenance (OAM) message within the group.
For the problem that the conventional ESDAI protocol cannot meet the requirement of information sharing among RBv members in the related art, there is no effective solution yet.